Lotus Development Corporation anticipates that Notes R3 customers will be eager to migrate to Notes R4 in order to take advantage of the product's many enhancements. These include easier user access to the power of Notes, significantly improved mobile/disconnected computing, better application development tools, enterprise server support, superior client-server messaging, and seamless Internet integration. Notes R4 has a new mail user interface that is virtually identical to cc:Mail, enhanced replication capabilities, and improvements in performance, scalability and ease of use.
Because the benefits of Notes R4 are so compelling, customers will probably find it easy to understand why they should migrate. Having made that decision, customers will naturally be more concerned about how they can manage the migration. Lotus has concentrated its development and support efforts to make the Notes R3 to Notes R4 migration:
*phased, so that an organization can begin enjoying the benefits of Notes R4 as soon as possible, well before the full migration is complete; and
*straightforward, so that an organization can confidently plan and conduct its migration with no surprises or disappointments.
Product migrations usually involve a "coexistence" period which may at times involve disruptions. Lotus, however, has designed Notes R4 in a way that minimizes the coexistence period and makes migrating to Notes R4 a straightforward and non-disruptive process. Migration is made seamless primarily by the fact that Notes R4 is compatible with Notes R3. This compatibility means that:
*all Notes R3 applications will run on Notes R4 without modification;
*all Notes R3 and Notes R4 servers, workstations, and databases will work together;
*Notes R3 clients work with Notes R4 servers and Notes R4 clients work with Notes R3 servers.
Because the two environments are entirely compatible, coexistence should be painless, and migration should proceed without snags. The duration of any organization's coexistence period will depend on many factors, such as the number of servers and users that need to be migrated, the number and location of remote sites, and the size of the IT staff. Therefore, Lotus recommends that customers perform considerable planning and analysis before launching their migration efforts
Lotus strongly recommends that customers migrate Notes in the following sequence: Notes servers, then Notes clients, then Notes applications. There are three advantages to this sequence.
First, organizations that follow this sequence will experience the smoothest migration. and ensure that disruptive situations are minimized. For example, applications will not be enhanced with Notes R4 features before users can access those features. It also avoids a situation in which users of R4 clients attempt to use new R4 features that are not available yet because a Notes R4 server is not available.
Second, there are specific features of Notes R4 servers that can be exploited by Notes R3 clients that will have a significant beneficial impact on the cost of ownership.
*Improved replication scheduling. Notes R4 now includes multiple replicators. Multiple replicators allow a single Notes server to conduct bi-directional replication with multiple servers at a time. This will increase the throughput by decreasing the time it takes to replicate information between multiple servers, while at the same time dramatically simplify the replication scheduling for sites with a large number of remote databases.
Third, migrating servers before the clients gives administrators a chance to become familiar with Notes R4 before rolling the new client software out to end users.
Server migration can be further broken down into the following recommended order: first hub servers, then user servers, then servers running other products. Hub servers should be migrated first because users don't generally access them, which means that if problems occur during the initial migration users aren't as likely to be affected. User servers, such as those that handle mail and applications, should be upgraded next. For servers running other products (gateways, etc.), organizations might want to wait until Notes R4 versions of those products become available before migrating the server.
Phase 1: Server migration. Upgrading a server is fairly simple. You install the server software and upgrade the Name & Address Book. Notes will automatically convert the file format and recreate indices for all databases the next time it runs COMPACT and UPDALL. Or you can run these steps manually.
These server processes can take several hours each depending on the amount of Notes data on the server and the speed of the server's processor. Lotus recommends measuring how long it takes to upgrade the first few servers and then using these metrics to estimate what a realistic daily upgrade load will be for the remaining servers in the organization.
Phase 2: Client migration. As with servers, this is fairly short and simple. Notes will automatically convert the desktop file format and create the Personal Address Book with entries from the Notes R3 Personal Address Book. Users can upgrade from any Notes R3.x release, but upgrading from R2 has not been tested as extensively as from Notes R3. The full version of the Notes R4 workstation software requires a minimum of 40 Mbytes of disk space.
Phase 3: Application migration. Bringing Notes R3 applications forward into Notes R4 is simple, since existing Notes R3 applications will work on Notes R4 without modification. As an extra precaution Lotus recommends testing mission-critical applications, as well as applications that contain "representative" functionality that is, functionality used in other applications.
Once the servers and workstations are running Notes R4, administrators can safely begin to introduce new Notes R4 functionality into existing applications and can create new applications using features introduced in Notes R4. The "golden rule" regarding applications is this: Do not add new Notes R4 functionality to applications that Notes R3 users will access. That's because Notes R3 users will receive error messages if they try to use parts of the application that are Notes R4-based. The error messages may give users the incorrect impression that there is something wrong with the system, and users may develop a negative impression about Notes R4. This may also lead to an increase in end-user calls to your internal support staff.
All server- and client-based API programs, including OLE- and FX-enabled applications, will run unmodified after upgrading to Notes R4, with one exception. The exception occurs when customers move from 16-bit Windows (Windows 3.x) to 32-bit Windows (Windows 95 or Windows NT) while at the same time moving from the 16-bit Windows version of Notes to the 32-bit Windows version of Notes. In this case other programs that interact with Notes, such as spreadsheet and word processing programs, will have to be upgraded to 32-bit versions. In other words, as long as Notes and the other programs that interact with Notes are all 32-bit, the applications that have been developed using Notes and the other programs will run unmodified.
For some organizations, the migration to Notes R4 will not be their first experience in a major Notes migration. In fact, for those organizations that upgraded from Notes R 2.x to Notes 3.0 will recall that the migration was not as straightforward as possible. A number of factors contributed to this, and Lotus has fully incorporated the lessons it learned from that migration into its plans for migrating customers to Notes R4.
Interoperability. Initially, Release 3.0 of Notes had some problems interoperating with Release 2.x. These problems were resolved but not before some customers experienced difficulties. As they roll out Notes R4, customers will benefit from the comprehensive interoperability testing that Lotus has conducted, and customers migrating to Notes R4 should expect smoother interoperability this time than they might have experienced when migrating to Notes R3.
One factor that contributed to the interoperability problems in the R2-Notes R3 migration was the fact that in Notes R3 Lotus added support for several new operating systems and networking protocols all at once. In hindsight it is clear that such an ambitious endeavor could lead to some problems. Nevertheless the minor glitches in the various implementations were resolved early in the Notes R3 product life. Now, as Lotus moves from Notes R3 to Notes R4 it does so on a very stable foundation.
Systems software expertise. Lotus has become more capable as a vendor of systems software. Selling systems software requires a different mindset and business model than selling desktop software. At the time of the Notes R3 introduction and migration Lotus was still establishing itself as a leading systems software vendor. Since then, Lotus has focused energy internally on improving its support and services as a systems software developer. Now as a subsidiary of IBM, Lotus is benefiting from an infusion of world class systems software personnel and experience.
Complete migration resources. Perhaps the biggest problem in the Notes R3 rollout was that Lotus did not provide adequate product migration information to customers. With Notes R4 Lotus is making available a variety of resources, including the following:
*Migration guide. This book, which ships with Notes R4, describes in detail the steps required in migration. It can be used as the foundation for an organization's migration.
*Release notes. This information, which also ships with Notes R4, will supplement the documentation supplied with Notes R4.
*Technical papers and FAQ documents. These papers will cover such topics as Name and Address Book migration, Server Consolidation, Security, Replication, and Single Copy Object Store. These documents will be available on the Lotus Web site, http://www.lotus.com.
*Migration seminars. Customers will be able to take advantage of Notes R3-to-R4 migration seminars offered by Lotus Enterprise Support Services, Lotus Authorized Education Centers or Lotus Business Partners.
A major product migration does not take place in one fell swoop, but in stages. There are five stages to a full migration: planning, preparation, pilot, production and leveraging. For some customers there will also be a rollback stage, although this is likely to be a rare exception rather than the rule.
Planning. Pre-migration planning is probably the most critical element of a successful migration. Time invested here will save time later in the project and result in a quicker overall implementation with fewer snags and headaches. During the planning stage new features in Notes R4 should be evaluated and "big wins" should be identified. Also a detailed upgrade schedule should be created. As part of the planning stage, customers should pay careful attention to infrastructure changes that are also being planned and to Notes-specific database and template changes that may be necessary for a successful migration.
It is a good idea to consider changes related to hardware, operating systems, networking protocols, and LAN/WAN architecture. Some of the issues to address include:
*Network configuration. Notes R4 includes new functionality called server passthru. Passthru allows a user to connect to one server and using that connection, access other Notes servers on the network. Now, mobile users only need to make a single call into a server when they are mobile. Using passthru, they have access to any server on the network and can replicate with them using that phone connection. Passthru also allows a LAN user to "pass through" a server to reach another server with which they don't share a common protocol (e.g. user may not have a protocol in common with server B, but have a protocol in common with server A, so they "pass through" A to get to B). Exploitation of server passthru functionality may require changes in network configuration. For example, instead of having modems attached to each server an organization might create a dial-in server with many modems attached to it and then use passthru to retrieve information from other servers. Also, organizations that implement server passthru may want to change the protocol configuration of Notes servers.
*Desktop operating system. An organization considering an operating system upgrade, (e.g., to IBM OS/2 Warp or to Microsoft Windows 95) should include this factor in its R3-to-R4 migration plans.
Lotus cautions customers that they should not carry out infrastructure changes at the same time as the Notes upgrade. Customers should make infrastructure changes either before the Notes migration, when they are still using the familiar Notes R3 environment, or after the Notes R4 migration has been completed and the organization feels comfortable enough with Notes R4 to introduce other infrastructure-related variables. Naturally, customers should plan and test these changes thoroughly before mixing them with any Notes environment.
In addition, there are specific changes to Notes databases that require the attention of migration planners.
*System Template Customization. Users who have not made changes to the system templates or to the database files created by the system templates will not have to do anything to the new Notes R4 system templates before beginning the migration process. But if the Notes R3 system templates or database files have been customized then the changes must be documented and administrators must decide whether to apply those changes in the Notes R4 system templates. Documenting system template changes and applying them to the Notes R4 system template is an important pre-migration step. The system templates with which organizations should be most concerned are the Name and Address Book, the log file and the mail box.
*Mail. The process for upgrading the mail server is the same as upgrading any Notes server. COMPACT and UPDALL will automatically upgrade the mail files to Notes R4 format. However, Lotus encourages you to upgrade the mail file design after the workstation upgrade rather than as part of the server upgrade to avoid user disappointment when they can't access new Notes R4 mail features. Notes provides three ways to upgrade mail databases to the Release 4 mail template.
2.After a workstation has been upgraded to Notes R4, users can upgrade their own mail file on their workstation by replacing it with the new Notes R4 template and then use Convert Categories to Folders Agent to create folders, subfolders, add categorized documents to those folders, and add uncategorized received documents to the Inbox.
3.Upgrading by mail. The Notes administrator can use a new form in the Public Address Book to compose Upgrade Messages that will be sent to one or more end-users. The message contains buttons for 1) upgrading the client from Release 3 to Release 4, and 2) upgrading the user's mailfile from Release 3 to Release 4.
Preparation. In this phase the Notes R4 migration team should set up test and production environments. Also during the preparation phase customers should consider standardizing their Notes R3 environment on the latest maintenance release of Notes 3.x before beginning migration to Notes R4. This step is recommended only if very early versions of Notes R3 are in use, however it is not required.
Pilot. In this phase the migration team should conduct a pilot migration project and test the migration process. They should test the mission critical applications that have been brought forward onto the new platform. User training should begin in this stage.
Production. Once the pilot roll-out has been tested and proven to be production-ready, the organization can roll out the new version to servers and users across the enterprise. Careful planning and preparation should ensure that this transitional period proceeds quickly and without glitches.
Leveraging. Once Notes R4 has been deployed across the organization the IT organization can begin to take full advantage of the all of Notes R4's new features and capabilities. Customers should plan carefully to deploy Notes R4 applications that make use of these new features (e.g., collapsible sections, Navigators, etc.) only to users who already have migrated to a Notes R4 client. That is, Notes R4 enterprise-wide applications should wait until rollout is complete before implementing new features in order to avoid a situation where Notes R3 users find themselves unable to access new Notes R4 application features. Of course, most organizations will be able to identify some applications that are narrow enough in scope (e.g., team-level, group-level, department-level) that can exploit new Notes R4 features, as long as all prospective users of the application have migrated to a Notes R4 client. Also, as pointed out above, some Notes R4 server features can be exploited immediately, even by Notes R3.x clients.
Rollback. Customers should not have to roll back to Notes R3, since any combination of Notes R3/Notes R4 workstations and servers will interoperate. Nevertheless, Lotus recommends that customers know how to roll back databases and servers, if only for the comfort of having a contingency plan. Rolling back a database involves changing the database from the Notes R4 file format back into the Notes R3 file format. Notes includes a facility that makes this simple.
Lotus has done extensive compatibility and coexistence testing on Notes R4, and Notes R3 customers should be able to migrate to the new environment without experiencing disruptions in Notes services.
Lotus advises customers to remember that time spent in planning will make the implementation of Notes R4 go smoothly. Also Lotus cannot emphasize too strongly its recommendation that IT organizations follow the server-client-application migration sequence. Customers who follow these guidelines should experience an easy transition and will realize the benefits inherent in the Notes R4 environment almost immediately.
Updated: 01/18/96 12:01:23 PM
This page created and managed with Lotus Notes and a pre-release (Beta 2) copy of Lotus InterNotes Web Publisher® Release 4.0.
License expires March 1, 1996.